A Tale of Leaky Data - Spooled Files

By Dan Riehl

A "data leak" is defined in Wikipedia as "the intentional or unintentional release of secure information to an untrusted environment." It can also be called a "data spill" or "data breach."

We are often deeply concerned about data leaking from our production database to the outside world. We often focus a great deal of effort on securing these precious data jewels we call files. But what about protecting the end result of these jewels—our printed reports? Our production reports consist of our precious data jewels, coordinated, manipulated, and cajoled into what becomes meaningful information in the form of a production report.

If we consider our database files to be sensitive, then our printed reports, which present that file data in a readable, organized format, must be protected with as much or, dare I say, more due diligence.

If your shop is like most, all, or almost all, output queues are left unsecured. For some strange reason, we assign *JOBCTL special authority to our end users. The result of this *JOBCTL assignment is that they can view and manipulate the reports generated by others. This is usually the root of the problem of data leakage via printed reports. A user with *JOBCTL special authority can, with few exceptions, view and control any printed report on the system.

Perhaps to avoid the potential of a data leak through a printed report, we configure the user accounts with the command line restriction LMTCPB(*YES). As a further step, we don't present a menu option that allows them to view the spooled files of others. That's a nice solution, but there still can be alternative methods to view and leak the data in our sensitive reports. One such method is through the IBM i Navigator for Windows (a.k.a. Operations Navigator) Basic Operations tab.

IBM i Navigator for Windows - Basic Operations Tab

When we install IBM i Access for Windows, one of the pieces of the typical basic install is IBM i Navigator - Basic Operations. Basic Operations allows the user to view and send messages, work with printers, and work with their jobs and with their spooled files, listed as Printer Output). But many administrators do not know that when you right-click an item in Navigator (as in Printer Output), the user can select whose printer output to view. The shipped value is "Show only my own reports," but as you can see in the following figure, right-click shows a "Customize" option that further allows the user to "Include" reports for the users he or she chooses, or even "Include" the reports for ALL users.

When "Include" is selected, the user can select from a plethora of options, as shown here. The user can even press the browse button to get a list of the users on the system and select the reports for just those users that might have the data he or she is looking for (to leak).

Once the reports are listed for your selected users, or output queues, or printers, double-clicking the report name presents the report in the Report Viewer window. Or, worse yet, the report can even be dragged onto the desktop and automatically and immediately be converted to a Windows text file in purely readable form. The sensitive report is then ready to attach to an email or copy to a handy USB drive. Leaking data for you!

Remediation of the Exposure

If output queues are correctly secured and users not endowed with powerful special authorities like *JOBCTL and *SPLCTL, your sensitive spooled files can be protected very nicely, even from IBM i Navigator access by unsanctioned users. But if users have too much authority to Output Queues or have *JOBCTL and/or *SPLCTL special authority, you can attempt to cripple their access with more draconian methods such as, 1.) Not installing IBM i Navigator at all, and 2.) Denying access to the Work with Spooled File (WRKSPLF) and/or Display Spooled file (DSPSPLF) commands.

Note: I am aware of at least one commercial software product that provides CL Command Controls that allow you to control the DSPSPLF command so that a User can only view the reports that were created by that user. I use this rule on my system. I love this level of control on CL commands, and encourage you to review some of the software packages out there that provide CL command Control for situations like this.

Recommendation: Secure your output queues correctly and don't provide *JOBCTL or *SPLCTL to your users. For this, see the Print Security Topic in the IBM Information Center.

To get a listing of your current output queue security setup, use the command Print Queue Authority (PRTQAUT ). Refer to the command help text for details.

About the Author

Dan performs IBM i security assessments and provides security consulting, remediation, forensic evaluations, and other customized security services for his clients.

Dan also provides training in all aspects of IBM i security and other technical areas through The 400 School, Inc.

Dan Riehl on LinkedIn